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FOREWORD 


The  Systems  Integration  and  Command/Control  Technical  Area  of  the  U.S.  Army  Research 
Institute  for  the  Behavioral  and  Social  Sciences  (ARI)  is  concerned  with  research  designed  to  help 
commanders  and  stat * in  the  critical  functions  of  assimilating  information  and  making  appropriate 
decisions,  to  develop  techniques  for  efficient  processing  and  use  of  information  by  operational 
personnel  in  tactical  situations,  and  to  maximize  effectiveness  of  Command  and  Control  systems 
through  the  most  efficient  use  of  human  abilities.  Present  Army  tactical  data  sy/ems  (e  g.. 
ARTADS,  IBCS)  have  been  developed  out  of  this  concern. 

A specific  research  project  under  the  Command  Systems  program  is  designed  to  optimize  the 
use  of  Army  tactical  data  systems  by  developing  compatible  computer  assisted  instruction  (CAI) 
packages  that  use  the  data  systems  to  support  individual  and  unit  training  requirements  when  the 
systems  are  not  required  for  tactical  operations.  This  Technical  Paper  is  the  first  of  several  reports 
to  come  from  the  project,  a preliminary  version  has  been  informally  printed  as  ARI  Research 
Memorandum  74-8.  The  entire  research  effort  was  begun  under  RDTE  Project  2Q062I06A72I  and 
is  responsive  to  requirements  of  RDTE  Project  2Q76373IA734,  FY  1975  Work  Program,  and  to 
special  requirements,  originally  from  the  Assistant  Chief  of  Staff  for  Force  Development  and  the 
Director  of  Army  Research,  now  from  the  Army  Training  and  Doctrine  Command  and  the  Project 
Manager,  Computerized  Training  System  (PM  CTS). 

ARI  research  in  this  area  is  conducted  as  an  in-house  effort  augmented  by  contracts  with 
organizations  selected  for  their  unique  capabilities  for  research  in  the  area.  The  present  study  was 
conducted  jointly  by  personnel  of  ARI  and  the  System  Development  Corporation,  with  special 
contributions  by  personnel  listed  in  the  section  "Sources  of  Information." 


APPLICATION  OF  TACTICAL  DATA  SYSTEMS  FOR  TRAINING:  DEVTOS 
FEASIBILITY  DETERMINATION  AND  SELECTION  OF  AN  INS  RUCTIONAL 
OPERATING  SYSTEM 

BRIEF 


Requirement: 

To  determine  the  feasibility  of  using  tactical  data  systems  in  support  of  individual  and  unit 
training  requirements  when  the  systems  are  not  required  for  tactical  operations;  and  to  select  an 
automated  instruction  (AM  system  compatible  with  an  existing  Army  tactical  data  system. 


Procedure: 

An  existing  Army  tactical  data  system-the  Developmental  Tactical  Operations  System 
(DEVTOS)  at  Fort  Hood,  Texas--was  analyzed  to  determine  whether  it  could  support 
computer-aided  instruction  (CAM-  First,  the  specific,  unique  characteristics  of  the  DEVTOS 
hardware  and  software  were  identified  and  analyzed  to  insure  that  both  could  support  CAI.  A 
survey  and  analysis  of  23  existing  CAI  systems-languages.  programs,  and  procedures -then 
determined  which  one  would  function  best  within  DEVTOS. 


Findings: 

A CAI  training  system  could  be  interfaced  with  DEVTOS  without  changing  the  system 
hardware  configuration  and  without  drastic  reprogramming  of  either  the  Al  system  or  the 
DEVTOS. 

Of  23  CAI  systems  identified  and  analyzed,  only  one-PLANIT  (Programming  Language  for 
Interacting  Teaching) -met  the  selection  criteria.  From  existing  versions  of  PLANIT  a single  viable 
system  was  developed  which  interfaced  with  DEVTOS  and  provided  suitable  instruction  programs. 


Utilization  of  Findings: 

An  operational  version  of  PLANIT  has  been  successfully  developed.  Because  PLANIT  is 
portable,  ARI  has  been  able  to  install  this  author/student  language  program  at  minimal  cost  on 
three  other  Army  data  systems  for  different  uses. 
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AI/DEVTOS  DEVELOPMENT 

This  report  addresses  the  first  of  four  interrelated  tasks  concerned 
with  determining  the  feasibility  of  applying  Tactical  Data  Systems  for 
training.  This  task  undertook  a to  analyze  the  Developmental  Tactical 
Operations  System  DEVTOS  at  Fort  Hood,  Texas  to  determine  if  it  could 
support  computer-aided  instruction  CAI ' , and  b to  survey  and  analyze 
existing  computer-assisted  instruction  programs  and  procedures  to 
determine  their  availability  and  feasibility  of  use  within  DEVTOS.  This 
report  analyzes  this  DEVTOS  hardware  and  software,  describes  the  survey 
of  CAI  systems,  and  summarizes  the  development  and  capabilities  of 
PLANIT--the  CAI  system  recommended  for  implementation  in  DEVTOS. 


Analysis  of  DEVTOS  Software  and  Hardware 

The  first  part  of  this  task  was  to  identify  and  analyze  the  unique 
and  specific  characteristics  of  the  DEVTOS  hardware  and  software  to  insure 
that  the  hardware  and,  to  a lesser  degree,  the  software  of  DEVTOS  were 
amenable  to  some  sort  of  automated  instruction  AI' . The  DEVTOS  system 
characteristics  were  next  evaluated  to  determine  ways  in  which  DEVTOS 
hardware  and  software  would  constrain  the  selection  of  an  AI  system. 

Then  the  potential  interface  problems  were  determined. 

The  conclusion  was  that  an  AI  training  system  CAI  could  be  inter- 
faced with  the  DEVTOS  without  drastic  reprogramming  of  either  the  AI 
system  or  the  DEVTOS. 


Survey  of  CAI  Systems 

The  survey  of  CAI  systems  covered  the  following: 

• Extensive  search  of  the  literature 

• Direct  communication  with  the  authors  of  the  systems 
being  considered 

• Analysis  of  CAI  system  using  the  DEVTOS  requirements  as  criteria 

• Analysis  of  CAI  systems  using  DEVTOS-oriented  capabilities  as 
criteria . 

As  a result  of  the  survey,  23  CAI  systems  were  identified  and  ana- 
lyzed. The  characteristics  of  these  systems  were  compared  with  the 
requirements  which  had  to  be  met  by  a CAI  system  in  order  for  it  to 
operate  in  DEVTOS.  Six  of  the  23  met  the  major  requirement  of  being 
written  in  either  the  COMPASS  or  FORTRAN  programming  language.  One 
system,  although  written  in  FORTRAN,  was  eliminated  because  it  had  no 
known  use  at  the  time.  The  five  remaining  CAI  systems  were  analyzed 

> • 


against  the  other  DEVTOS  requirements  and  also  against  the  minimum  essen- 
tial elements  for  a practically  functional  CAI  system.  By  the  time  these 
requirements  and  elements  had  been  considered,  two  CAI  systems  remained-- 
CHIMP  and  PLANIT — which  met  the  CAI  requirements  and  elements  specified. 
There  were  no  known  drawbacks  to  implementing  either  of  these  on  DEVTOS. 
However,  PLANIT--as  compared  to  CHIMP--had  a known  transferability 
record,  was  currently  on  a Control  Data  Corporation  (CDC)  computer,  and 
had  many  additional  capabilities  in  regard  to  course  development  and 
recordkeeping.  Consequently,  PLANIT  was  logically  derived  as  the  CAI 
system  recommended  for  implementation  in  DEVTOS.  Ihe  U.S.  Army  Research 
Institute  ARl)  proceeded  to  obtain  several  versions  of  PLANIT.  With 
these  as  a point  of  departure  ARI  developed  a single  viable  system  which 
would  interface  with  the  available  hardware  and  software  within  the 
constraints  of  the  Fort  Hood  system,  produce  instructional  programs  with 
the  requirements  dictated  by  the  courseware  strategies,  and  utilize  and 
adapt  the  best  segments  of  the  different  versions  of  PLANIT. 


Instructional  System  Development  and  Basic  PLANIT  Capabilities 

As  part  of  this  project,  a survey  of  existing  AI  systems  was  con- 
ducted to  determine  which,  if  any,  would  meet  the  needs  of  the  project. 
Project  needs  included  a)  an  AI  system  integrated  into  a tactical  data 
system  DEVTOS)  which  was  not  specifically  designed  for  AI,  and  (b) 
courseware  developed  which  the  AI  software  selected  for  the  experiment 
could  execute  and  modify.  This  section  discusses  the  integration  of 
this  system  within  the  operational  environment  at  the  test  facility. 

Fort  Hood,  Texas. 

As  one  of  the  first  integration  activities,  a proposal  was  reviewed 
which  contained  a plan  for  integration  of  an  AI  system  within  DEVTOS  in 
which  the  current  operating  system  would  remain  basically  intact  and  an 
AI  system  would  be  customized  to  operate  within  that  system.1  For 
several  reasons  this  was  not  felt  to  be  the  best  approach.  First  a 
customized  AI  system  would  be  untested  and  would  probably  require 
extensive  checkout.  Secondly,  a customized  AI  system  would  not  be  the 
off-the-shelf  product  desired,  and  its  transferability  and  utility  within 
other  tactical  systems  assuming  project  results  indicated  that  AI  in 
tactical  computers  was  feasible)  would  be  severely  curtailed.  Availa- 
bility of  the  AI  capabilities  and  functions  considered  necessary  to  meet 
project  commitments  was  questionable.  Finally,  upon  completion  of  Task 
1,  it  was  concluded  that  an  existing  AI  system  PLANIT  could  be  integrat- 
ed into  DEVTOS  to  provide  the  functional  capabilities  for  courseware 
development,  modification,  instruction  presentation,  and  student  record- 
keeping--all  considered  necessary  in  an  AI  system.  (Student  record- 
keeping later  proved  to  be  a serious  deficiency  in  all  versions  of  PLANIT.) 


’From  Bunker-Ramo  Technical  Note  "MASSTER  Test  122 --Computer  Assisted 
Instruction  CAI)  Concept  Paper,"  February  1^73,  prepared  for  the  U.  S. 
Army  Computer  Systems  Command. 


The  AI  system  selected  was  PLANIT  (Programming  LANguage  for  inter- 
active Teaching) , considered  to  be  the  most  effective  and  least  costly 
AI  system  with  which  to  meet  project  commitments.  PLANIT,  as  a computer 
program  system  for  AI,  provides  an  AI  author  language  and  computer  pro- 
grams that  make  a variety  of  operations  available  to  the  user.  Briefly, 
PLANIT  allows  an  author  to  enter  instructional  material  into  the  computer- 
interactively  on-line,  or  off-line  as  card  inputs--and  to  store  this 
material  in  designated  sequences  on  appropriate  storage  devices.  The 
author  may  enter  his  material  in  any  of  several  formats  and  can  imme- 
diately review,  edit,  and  revise  the  instructional  material  as  necessary. 
Completed  instructional  programs  (AI  lessons)  are  presented  to  a student 
at  the  remote  terminal  through  the  execution  facility  of  the  system. 

PLANIT  contains  an  interactive  calculation  language.  The  complete 
computation  language  may  be  used  by  an  author  interactively  or  may  be 
used  as  instructions  to  PLANIT  in  an  instructional  program.  A subset  of 
the  calculation  language  is  available  to  the  student  as  he  executes 
instructional  material,  unless  its  use  is  prohibited  by  the  lesson  author. 
The  student  can  construct  his  own  mathematical  functions  as  well  as  use 
the  functions  an  author  makes  available  to  him. 

PLANIT  also  permits  an  author  to  specify  alternative  actions  to  be 
executed  based  on  student  response.  The  criteria  for  conditional  feed- 
back or  branching  can  be  based  upon  the  cumulative  performance  records 
of  the  student  which  are  automatically  kept  by  PLANIT  or  upon  records 
kept  by  programming  statements  in  the  lesson.  PLANIT  also  provides 
response-processing  routines  to  aid  in  matching  student  responses  against 
the  author's  anticipated  responses.  These  aids  to  response-matching 
include  phonetic  equivalency  comparisons,  equating  uppercase  and  lowercase 
characters,  searching  for  key  words  in  the  response,  searching  for  key 
characters  in  the  response,  automatic  matching  of  numeric  equivalents, 
and  automatic  matching  of  algebraically  equivalent  expressions. 

Finally,  PLANIT  provides  for  on-line  interactive  control  of  off-line 
utility  operations.  This  includes  generating  instructional  material  from 
or  onto  cards,  obtaining  a listing  of  completed  material,  and  performing 
a variety  of  maintenance  tasks  related  to  student  performance  records 
and/or  manipulation  of  instructional  material  stored  on  disk  or  tape. 

The  System  Development  Corporation  (SDC)  supplied  a computer  tape 
of  its  I97O  version  of  PLANIT  to  ARI  in  February  1973  to  permit  ARI 
personnel  to  become  familiar  with  PLANIT  coding.  During  March-June  1973 
SDC  served  primarily  as  a consultant  toward  the  PLANIT/DEVTOS  integra- 
tion, reviewing  and  making  recommendations  concerning  a second 
functional  paper  in  which  a modified  PLANIT  would  be  integrated  into  the 
existing  DEVTOS.  SDC  pointed  out  that  because  of  PLANIT' s internal 
logical  design,  whereby  an  interdependency  of  operations  exists  among 
functional  areas,  it  was  in  the  best  interests  of  the  project  to  partition 
and  overlay  an  existing  version  of  PLANIT  within  DEVTOS  rather  than 
attempt  to  modify  or  delete  existing  functional  capabilities. 


ARI  investigated  the  possibility  of  letting  a contract  with  a soft- 
ware house  for  developing  a fully  operational  PLANIT  with  Machine  Inter- 
face I/O  Program  (MIOPS).  Cost  estimates  were  too  high  and  estimated 
completion  date  too  distant  to  make  this  approach  feasible,  particularly 
since  an  anticipated  early  release  of  the  National  Science  Foundation 
(NSF) /Purdue  University  version  of  PLANIT  in  early  June  1/731  never 
materialized.  Thus,  it  became  necessary  for  ARI  to  develop  a workable 
PLANIT.  The  writing  of  the  MIOPS  and  the  integration  of  these  PLANIT 
components  with  the  communication  package  was  contracted  out  to  the 
Bunker-Ramo  Corporation  (BRC)  under  the  aegis  of  the  U.  S.  Army  Computer 
Systems  Command  (USACSC)  in  accordance  with  a statement  of  work  supplied 
by  ARI.  This  software  interface  permitted  the  use  of  the  l'CDC)  general 
operating  system  MSOS  to  drive  the  DEVTOS  equipment,  thereby  eliminating 
the  need  to  rely  on  the  special  DEVTOS  software  system. 

The  early  possession  of  a version  of  PLANIT  permitted  ARI  to  gain 
some  familiarity  with  PLANIT  logic,  but  this  early  version  had  known 
deficiencies,  including  an  inability  to  properly  maintain  student 
records,  which  prevented  its  further  programming  development.  Although 
the  NSF/Purdue  version  later  called  PLANIT  1.0)  was  not  available,  ARI 
obtained  a copy  of  the  Michigan  State  University  (MSU)  version--a  lineal 
descendent  of  the  Freiburg  version,  as  is  the  NSF/Purdue  version.  With 
some  consultation  with  MSU  personnel  (particularly  Dr.  Rahimi) , ARI 
installed  an  improved  version  of  the  MSU  PLANIT  modified  to  run  in  20K 
of  memory,  first  at  the  ARI  facility  in  Arlington,  Virginia  and  later  on 
the  DEVTOS  at  Fort  Hood.  The  final  ARI  version  of  PLANIT  was  designated 
PLANIT  1.1  by  the  PLANIT  Users  Executive  Committee  during  the  fall  of  197*+ 

During  July-August  1973 • specific  functional  problems  were  identified 
during  field  tests  and  integration  of  AI  software  and  AI  courseware. 
Inhouse  tests  at  ARI,  joint  SDC-ARI  tests  at  ARI,  and  joint  tests  at 
Fort  Hood  determined  that  a number  of  PLANIT  software  functions  were  not 
working  according  to  design  intent,  i.e.,  the  earlier  SDC  documented 
concepts  of  PLANIT  and  the  current  available  PLANIT  versions  differed  in 
several  major  aspects.  These  determinations  were  based  on  on-line  runs 
using  AI  courseware  and/or  special  test  cases  (PLANIT  frame  sequences) 
constructed  by  the  lesson  authors.  Design  intent  was  determined  by 
functional  specifications  presented  in  the  PLANIT  Author's  Guide 
SDC  TM^L) -4422/001/01)  2 and  the  PLANIT  Language  Reference  Manual 
SDC  TM  L) -4422/002/01.  These  were  used  as  the  standard  against  which 


2Bennik,  F.  D.,  and  Frye,  C.  H.  PLANIT  author's  guide  (TM(L) -4422/001/01) 
Santa  Monica,  Calif.:  System  Development  Corporation,  October  1,  1970. 

3Butler,  A.  K.,  and  Frye,  C.  H.  PLANIT  language  reference  manual  (TM(L)- 
4422/002/01).  Santa  Monica,  Calif.:  System  Development  Corporation, 

October  1,  1970. 


- 4 - 


to  measure  PLANIT's  functional  performance  because:  (1)  they  define 
system  reaction  under  given  conditions  of  courseware  encoding;  (2)  an 
interim  version  of  these  documents,  co-authored  by  the  PLANIT  designer 
and  his  staff,  was  used  as  the  PLANIT  functional  specification  at  the 
time  SDC  undertook  to  make  PLANIT  a machine-transferable  system  under 
contract  to  the  National  Science  Foundation;  and  (3)  AI  project  lession 
authors  needed  a language  specification  for  designing  and  encoding  AI 
materials.  Im  ambiguous  situations,  the  functional  capabilities  and 
design  intent  were  determined  by  telephone  contact  with  the  designer  of 
NSF  PLANIT,  Dr.  Charles  H.  Frye,  PLANIT  Director,  Northwest  Regional 
Educational  Laboratory,  Portland,  Oregon. 

Table  1 summarizes  the  functional  problems  identified  and  alleviated 
by  joint  effort  before  the  AI  field  test  began.  The  problems  are  cate- 
gorized functionally,  according  to  whether  they  were  problems  of  presen- 
tation control,  response  acceptance  and  processing,  program  control, 
decision  functions,  or  system  support:.  For  an  explanation  of  the  PLANIT 
language  shown  in  parentheses  in  the  table,  refer  to  the  PLANIT  docu- 
mentation referenced  above. 

Of  the  problems  listed  in  Table  1,  those  dealing  with  decision  frames 
were  solved  primarily  by  installing  a rewritten  PLANIT  decision  logic 
into  the  Fort  Hood  PLANIT.  This  deck  was  rewritten  at  Northwest  Regional 
Educational  Laboratory  and  was  installed  by  ARI  at  Fort  Hood.  Another 
change  solved  the  problem  with  multiple-decision  statements  of  pattern 
form. 

Another  problem  for  users  in  the  student  mode  was  slow  response  time, 
ranging  from  6 to  12  seconds  for  response  frames,  and  6 to  lL  seconds — up 
to  as  much  as  50  seconds--for  decision  frames.  These  response  times 
were  speeded  up  to  tolerable  levels  for  the  AI  field  experiment  through 
ARI's  use  of  the  high  speed  drum  for  handling  the  overlays. 

It  should  not  be  construed  that  all  functional  capabilities  of  PLANIT 
were  subjected  to  a detailed  verification,  as  this  was  neither  the  case 
nor  the  intent  of  this  phase  of  the  project  activity.  The  results  of 
this  integration  effort  did,  however,  produce  a viable  PLANIT  that  fully 
supported  the  requirements  of  this  project.  This  is  the  version  of 
PLANIT  subsequently  designated  Version  1.1  by  the  PLANIT  Users  Group. 

The  majority  of  presentation,  response  processing,  program  control,  and 
decision  functions  of  PLANIT  Version  1.1  appear  to  operate  correctly. 
However,  a number  of  PLANIT  calculation  capabilities  (e.g.,  matrix, 
algebraic,  and  review  statements)  were  not  tested  in  this  experiment. 
Further  test  of  system  utility  functions  (off-line  support  activities)  is 
also  warranted. 


Table  1 


PLANIT  DEVELOPMENT  MILESTONES  DURING  Al  FIELD  TEST 


PROBLEM  AREA  ANO  PROBLEM 

DISPOSITION 

Presentation 

PLANIT  line  skip  control  character  was  not  working 
at  student  consoles.  The  effect  of  this  was  to  undo 
the  display  formats  created  during  lesson  building. 

This  occurred  only  at  Fort  Hood. 

CRT  driver  was  modified  by  ARI  to  correct 
this  condition  at  Fort  Hood. 

PLANIT  operator's  message  (BUSY)  appeared  inter- 
mittently during  lesson  execution. 

Result  of  ARI  changes  to  PLANIT; 
corrected  at  Fort  Hood. 

Response  Acceptance  and  Processing 

Use  of  response  processing  function  (TEXT)  in 
lessons  caused  abort  of  PLANIT. 

TEXT  function  stated  to  lie  operating  in 
Freiberg  version  of  PLANIT  did  not  work. 
TEXT  function  removed  from  all  courseware. 

No  match  of  a correct  numeric  response  where 
the  first  character  was  a decimal  point  (e.g., 
the  student's  response  0025  would  not  match 
the  author's  A+  .0025). 

Modified  courseware  to  space  between  + 
and  decimal  point  (e  g.,  A+  .0025) 

Response  to  multiple-choice  frame  other  than  a 
letter  tag  fiom  multiple-choice  list  caused  PLANIT 
to  abort,  rather  than  printing  the  prompt 
CHOOSE  ONE  OF  THE  ABOVE  LETTERS 

Fixed  at  ARI  prior  to  Fort  Hood  by  adding 
additional  card  in  cold  start  deck. 

Program  Control  Functions 

Lesson  control  word  (RELATED)  operated  incon- 
sistently in  constructed-response  and  multiple 
choice  frames. 

RELATED  found  to  operate  correctly  in 
Group  3 of  Q frames  and  Group  4 of  M 
frames. 

Timed  pacing  (WAIT)  found  inoperative. 

Worked  when  used  with  CRT  after  removing 
an  MSU  correction. 

Logic  for  automatic  feedback  of  correct  answer 
found  to  be  reversed  correct  answers  prefaced  by 
a number  tag  were  treated  as  literals  for  feed- 
back, whereas  correct  answers  prefaced  by  a letter 
tag  were  treated  as  a numeric  expression  in  feedback. 

Fixed  at  ARI  prioi  to  Fort  Hood. 

Second  or  subsequent  unanticipated  response  tags 
caused  PLANIT  to  abort. 

Fixed  at  ARI  prioi  to  Fort  Hood. 

Decision  Frames'  Loqic  and  Records 

Logic  of  summary  form  of  decision  statement  (RIGHT, 
WRONG,  SEEN)  found  to  be  incorrect  or  inconsistent 
in  operation. 

Tested,  fixed  by  Dr.  Frye,  and  retested  at 
Fort  Hood. 

Logic  of  pattern  form  founrl  incorrect  when  operating 
over  a series  of  decision  statements. 

Tested,  fixed  by  Dr.  Frye,  and  retested  at 
Fort  Hood. 

Logic  of  compound  decision  statements  with  clauses 
connected  by  AND  and  OR  treated  both  as  OR 
clauses. 

Tested,  fixed  by  Dr.  Frye,  and  retested  at 
Fort  Hood. 

Frame  si /e  was  too  small. 

Increase  of  frame  si?c  at  Fort  Hood. 

laoie  i continued 


PROBLEM  AREA  AND  PROBLEM 


Extraneous  characters  were  intermittently 
inserted  into  lesson  disk  file  when  lesson 
was  executed  by  an  author.  If  characters 
had  overwritten  frame  control  characters, 
subsequent  lesson  execution  would  abort 
PLANIT.  If  characters  had  overwritten 
display  and  feedback  messages,  subsequent 
lesson  execution  displayed  the  extraneous 
characters. 

Intermittent  problems  occurred  after 
deleting  a lesson  and  its  student  records 
from  a disk,  wherein  subsequent  lesson 
construction  left  both  named  and  un- 
named lesson  files  on  disk. 

Use  of  command  to  name  a lesson 
(SAVE)  frequently  resulted  in  unnamed 
lessons  left  on  disk  with  further  access 
denied. 

Each  successive  punr*  out  of  a given 
lesson  shifted  lines  one  space  to  the 
right,  until  display  width  was  exceeded. 

Failed  to  store  lessons  onto  tape  or 
to  retrieve  lessons  from  tape. 

Failed  to  transfer  student  performance 
records  onto  tape,  and  to  list  student 
records  on  high-speed  printer. 

Interfaced  unreliably  with  communications 
software  and  system  hardware. 

PLANIT  intermittently  dropped  lesson 
frames  for  unknown  reasons  during 
online  editing  and  building. 


DISPOSITION 


Problem  identified  at  Fort  Hood. 


Procedure  changes  at  Fort  Hood  eliminated 
the  problem. 


Procedure  changes  at  Fort  Hood  eliminated 
the  problem. 


Fixed  at  Fort  Hood. 


Alternative  procedure  was  installed  at 
Fort  Hood. 

Alternative  procedure  was  installed  at 
Fort  Hood. 


Fixed  at  Fort  Hood  by  development 
of  new  CRT  software  prior  to  Al 
experiment. 

Status  uncertain-precise  reason  for 
problem  uncertain;  problem  alleviated 
by  updating  card  decks  and  rebuilding 
lesson. 
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ANALYSIS  OF  DEVTOS  HARDWARE  AND  SOFTWARE 


This  detailed  section  describes  the  findings  from  an  examination  of 
the  hardware  and  software  characteristics  of  DEVTOS,  identifies  the 
requirements  which  had  to  be  met  by  an  automated  instruction  AI1*  pro- 
gram to  operate  within  the  DEVTOS  system,  describes  some  potential  inter- 
face problems,  and  discusses  some  of  the  characteristics  of  the  DEVTOS 
hardware  and  software. 

The  general  operation  was  as  follows:  Students  used  cathode  ray  tube 
CRT^  terminals  for  both  input  and  output.  Textual  information,  ques- 
tions, and  remedial  feedback  were  displayed  to  the  student  on  his  CRT. 
Using  the  typewriter-like  keyboard  on  the  CRT,  the  student  typed  in  his 
answers  to  questions  or  used  predetermined  codes  to  start  or  advance 
through  the  lesson.  The  computer  responded  appropriately  with  new 
displays--new  pages  of  text,  feedback,  or  remedial  data.  Ten  CRT 
terminals  were  used  for  students  with  two  more  used  for  monitoring  and 
controlling  purposes.  Student  results  could  be  output  on  hard  copy 
immediately  after  a course  was  completed,  using  the  typewriter  which  was 
paired  with  each  CRT. 


Evaluation  of  DEVTOS  Hardware  and  Software  for  Al  Use 

Certain  general  criteria  must  be  met  by  any  computer  system  for  the 
system  to  support  AI.  The  DEVTOS  hardware  and  software  were  evaluated 
in  terms  of  these  criteria  to  determine  if  AI  was  possible  on  the  DEVTOS 
configuration.  The  broad  characteristics  required  for  AI  are  identified 
in  the  following  blocks  and  the  DEVTOS  CDC  $300  capability  is  discussed 
relative  to  these  characteristics. 

1.  A means  of  inputting  AI  system  and  AI  course  information  into 
the  computer  must  exist.  As  the  CDC  3;>00  computer  of  the  DEVTOS  has  both 
card  reader  and  magnetic  tape  inputs,  input  was  no  problem. 

2.  Adequate  storage  space  memory)  to  store  the  AI  system  and  AI 
course  materials  is  required.  The  DEVTOS  computer  system  has  a total 
storage  capacity  in  excess  of  3 million  words  or  20  million  characters. 
Assuming  1000  characters  per  course  frame,  there  is  storage  for  20,000 
frames.  This  would  probably  accommodate  over  200  hours  of  instruction, 
ample  storage  for  the  course  materials.  Most  AI  software  systems  require 
about  °00,000  characters  of  space  for  operation,  which  is  well  within  the 
DEVTOS  capacity. 

5.  An  adequate  terminal  device  must  be  available  for  the  student  to 
use . DEVTCS  has  teletype,  typewriter,  and  CRT  terminal  inputs.  Any  of 
these  are  adequate.  The  best  of  these  is  the  CRT  terminal  because  of 
its  speed,  silent  operation,  and  availability.  Also,  the  CRT,  unlike 
the  typewriter,  prevents  the  student  from  looking  back  for  answers  to 
criterion  items.  Since  he  only  has  the  current  display  frame  available, 
the  student  is  forced  to  learn  the  material. 


4 . A means  must  exist  to  pass  control  to  the  AI  system  so  it  can 
operate.  DEVTOS  was  designed  in  a modular  fashion  to  facilitate  changing 
and  adding  features.  It  has  a complete  operating  system  and  executive 
incorporated  into  it.  While  all  the  existing  software  is  custom  built, 
the  modular  design  and  table  driven  concept  make  it  possible  to  add  a 
specific  applications  package  such  as  an  Al  system.  The  task  of  inter- 
facing the  DEVTOS  software  and  the  AI  system  software  could  have  been  a 
significant  problem  if  the  AI  system  were  poorly  documented,  did  not 
identify  the  interface  points,  or  were  not  designed  to  be  machine  trans- 
ferable; therefore  documentation  and  machine  transferability  were 
included  among  the  requirements  which  the  candidate  public  domain  CAI 
systems  were  asked  to  meet.  An  AI  system  with  good  documentation,  machine 
transferability,  and  interface  points  would  operate  within  DEVTOS  under 
the  control  of  the  DEVTOS  executive.  The  Tactical  System  Development 
Group  (TSDG)  at  Fort  Hood,  which  programs  and  maintains  DEVTOS,  cooper- 
ated closely  to  insure  this  coordination. 


Requirements  for  an  AI  System 

After  determining  that  DEVTOS  met  the  four  criteria  for  supporting 
AI,  the  DEVTOS  system  was  examined  to  determine  what  constraints  its 
hardware  and  software  would  place  on  an  AI  system.  These  constraints 
then  became  the  AI  requirements: 

1.  The  AI  system  must  be  able  to  operate  on  the  CDC  3300  computer; 
either  by  finding  an  AI  system  already  operating  on  a CDC  3000  series 
computer  or  by  installing  a machine  transferable  AI  system  on  the  3300. 

2.  The  AI  system  must  be  written  in  either  the  COMPASS  or  FORTRAN 
programming  language  since  these  are  the  only  languages  usable  with 
DEVTOS . 

3.  The  AI  system  must  operate  within  the  DEVTOS  hardware  limitations: 

24-bit  words  with  4 @ 6-bit  bytes  per  word 
81,320  words  of  c.ore  memory 
4,137,440  words  of  auxiliary  disk  storage 
1,048,376  words  of  auxiliary  drum  storage 
3 magnetic  tape  uiits 
1 card  reader 
1 line  printer 

See  the  section  on  DEVTOS  hardware  characteristics  for  further  details 
of  the  hardware  limitations,  characteristics,  and  a discussion  on  their 
impact  on  AI. 

4.  The  AI  system  must  be  operable  or  modifiable  to  operate  under  the 
DEVTOS  executive  program.  This  includes  such  things  as  having  defined 
entrant  and  reentrant  points  and  having  the  ability  to  be  segmented  into 
4K  modules. 
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% The  AI  system  must  be  able  to  handle  at  least  10  students  on-line 
at  CRT  terminals.  In  addition,  a terminal  should  be  available  for  control 
purposes  and  another  for  monitor  purposes. 

6.  The  AI  system  must  have  adequate  documentation  so  that  programming 
interfaces  may  be  identified,  specified,  programmed,  and  tested 


The 

AI  system  must  be  able  to 

process 

or 

use 

the  following 

characters  which 

arc  available  on  the 

CRT: 

a 

A-Z 

Letters 

n) 

> 

Semicolon 

b> 

0-,< 

Numbers 

o) 

/ 

Slash 

c 

Space 

p) 

; 

Colon 

d) 

Period 

q) 

■J 

At 

o' 

Comma 

r^ 

J 

Exclamation 

n 

- 

Hyphen  or  minus 

s) 

? 

Question 

+ 

Plus 

t) 

ti 

Quotes 

h'1 

= 

Equals 

u) 

/* 

Number 

0 

/- 

Percent 

v) 

Less  than 

P 

• 

Asterisk 

w) 

Greater  than 

k) 

•% 

Dollar 

x) 

i 

Prime 

1) 

Left  parenthesis 

y) 

L 

And 

m 

) 

Right  parenthesis 

In  DEVTOS  a through  k were  the  only  legal  characters  for  use  in 
message  texts.  This  would  not  preclude  the  use  of  the  full  set  in  AI 
display  frames  but  did  limit  the  textual  responses  from  the  students  to 
those  characters  in  a through  . 

. The  AI  system  must  be  capable  of  producing  on-line  student  result.1 
at  a hard  copy  terminal,  to  satisfy  the  research  design  requirement  that 
hard-copy  feedback  be  available  immediately  upon  course  completion. 


Apparent  Interface  Problems 

Even  before  the  actual  CAI  system  had  been  selected,  certain  inter- 
face problems  appeared  likely  on  the  basis  of  available  data.  The  under- 
lying assumption  was  that  the  AI  system  would  be  an  entity  complete  in 
itself  which  would  perform  all  the  AI  functions. 

The  first  problem  was  with  the  student  interface.  Since  the  preferred 
student  interface  was  with  the  CRT  display  terminal,  several  programming 
modifications  were  necessary.  The  Remote  Station  Data  Terminal  (RSDT)  had 
to  be  reprogrammed  to  permit  both  input  and  output  from  the  CRT.  The 
formats  used  for  the  AI  display  also  had  to  be  programmed  into  the  1700. 
The  CDC  y)00  required  reprogramming  in  both  the  input  and  output  inter- 
faces with  the  1~00.  If  the  inputs  were  to  be  error  and  validity  checked, 
this  too  would  have  to  be  programmed,  (if  an  AI  system  were  to  have  its 
own  input  error-checking  capability,  no  additional  error-checking  pro- 
gramming would  be  required.) 
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Interface  between  the  DEVTOS  executive  and  the  AI  package  was  another 
programming  task  which  had  to  he  accomplished.  The  DEVTOS  executive  has 
certain  conventions  in  passing  control  to  an  application  program  which 
must  be  met,  i.e.,  the  driving  table.  The  interrupt  processing  functions 
of  the  DEVTOS  executive  are  based  on  tactical  assumptions  which  are  not 
always  valid  for  AI  training  purposes.  Other  interface  considerations, 
such  as  character  incompatabilities,  required  that  small  translator 
routines  be  written  so  that  the  DEVTOS  executive  and  the  AI  package  could 
accurately  communicate  with  each  other. 

Hie  interface  between  the  AI  package  and  the  data  base  of  frame 
information  is  typically  a machine-specific  program  which  is  tailored 
when  the  AI  package  is  installed.  The  AI  package  required  a translator 
routine  to  enable  it  to  retrieve  frames  of  textual  material. 

The  interface  between  the  AI  package  and  the  input  and  output  devices 
was  another  piece  of  required  machine-specific  software.  This  consisted 
of  a program  linkage  to  enable  the  AI  package  to  talk  to  and  understand 
the  terminal  devices,  probably  in  the  nature  of  a simple  translator 
routine . 

A processor  needed  to  be  programmed  to  read  the  AI  system  into  the 
computer  and  to  read  in  the  instructional  frames.  These  would  have  to  be 
read  from  either  cards  or  tape  and  stored  on  disk  or  drum.  The  storage 
locations  of  the  AI  system  and  the  data  base  of  instructional  material 
would  have  to  be  known  by  the  DEVTOS  executive  and  the  AI  system. 

The  AI  system  had  to  be  divided  into  40y6-word  segments  in  order  to 
meet  the  DEVTOS  dynamic  core  allocation  requirements  and  to  switch 
information  from  auxiliary  storage  to  main  storage.  BRC  suggested  that 
this  be  done  manually  since  no  computer  utility  program  existed  to  do  it 
automatically. 

A special  copy  of  the  DEVTOS  software  had  to  be  created  to  incorporate 
appropriate  programming  for  the  above  considerations.  In  addition,  the 
tactical  functions  had  to  be  blocked  to  keep  them  from  being  turned  on 
accidentally  by  a student  during  AI  training  sessions. 


DEVTOS  Hardware  Characteristics 

The  DEVTOS  is  a highly  mobile  system.  All  hardware  components  of 
the  system  are  installed  in  vans  or  trailers. 

Central  Computing  Center  CCC) 

The  CCC  is  the  name  given  to  the  central  computer  complex  and  the 
vans  which  house  the  computers.  The  computer  is  basically  a CDC  3500 
which  is  a large-scale  business-oriented  machine,  with  the  floating  point 
arithmetic,  multiprogramming,  and  real-time  communications  options 
installed.  The  computer  has  the  following  characteristics: 
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Word  size:  24  bits 

Number  of  characters /word:  4 

Number  of  bits/per  byte  (character):  6 

Character  coding:  BCD 

Memory  capacity  (words):  81,920 

Memory  capacity  (characters):  327,680 


The  memory  capacity  had  been  expanded  to  a total  of  5.287.936  words 
(21,151,7^4  characters)  by  the  addition  of  both  disc  and  drum  auxiliary 
memory  devices.  TVo  CDC  854  disk  drives  have  the  combined  capacity  of 
4,157.440  words  or  16,629,760  characters.  (Each  disc  can  hold  2,078,720 
words  or  8,314,880  characters.)  The  average  access  time  for  the  disk  is 
107o  milliseconds.  The  drum  is  a CDC  863  mass  storage  drum  which  can 
contain  1,048,576  words  (4,194,304  characters).  The  average  access  time 
for  the  drum  is  17  milliseconds. 

The  computer  has  the  following  peripheral  devices: 

1 Operator  Console 

1 Card  Reader  capable  of  reading  1200  cards  per  minute 
1 Card  Punch  capable  of  punching  250  cards  per  minute 
5 Magnetic  Tape  Drives  (7  track)  which  are  IBM  compatible 
1 Line  Printer  capable  of  printing  1000  lines  a minute 
Plus  appropriate  controllers  for  the  devices 

The  principal  external  interface  of  the  central  computer  is  by  means 
of  data  set  adapters  which  couple  with  the  crypto  equipment.  The  crypto 
equipment  is  linked  by  either  radio  or  telephone  lines  to  crypto  equip- 
ment at  the  Remote  Station  Data  Terminal  (RSDT).  The  RSDT  contains  a 
CDC  1700  computer  which  served  as  a terminal  device  controller,  message 
buffer  and  message  switching  device  as  well  as  a repository  for  various 
message  format  skeletons.  Figure  1 shows  the  relationship  between  the 
Central  Computer,  Remote  Computer  and  terminal  User  Input  Output  Devices 
(UIOD's). 

The  cryptographic  link  suggested  that  in  the  AI  application  all  AI 
information  would  pass  through  the  encryption/decryption  equipment  (see 
Figure  l)  . This  had  to  be  explored  to  determine  if  (l)  all  data  would 
pass  through  the  crypto  equipment,  (2)  the  mass  of  AI  data  would  have  an 
adverse  impact  on  the  malfunction  rate  of  that  equipment  and  (3)  if  some 
device  or  technique  could  be  used  to  bypass  the  crypto  equipment. 

Remote  Station  Data  Terminal  (RSDT) 

The  RSDT  contains  the  CDC  1700  computer,  its  associated  crypto  equip- 
ment, the  terminal  devices  (UIOD's)  and  the  necessary  cables  and  control- 
lers to  operate  the  UIOD's.  The  1700  computer  is  a small  commercially 
available  computer  frequently  used  for  process  control  in  manufacturing 
applications  and  for  terminal  control  and  message  switching  as  it  is  in 
DEVT0S.  The  1700  has  the  following  characteristics: 
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Central  Computer  Complex 


Adapted  from  BKC  Tactical  Operations 
System  Software  pamphlet. 


Number  of  bits  per  character 
Type  of  character  coding 
Number  of  characters  per  word 
Number  of  bits  per  word 
Number  of  words  per  module 
Number  of  storage  modules 
Total  number  of  words  available 


8 

ASCII 

2 

1 6 

4096  ('  992  characters) 

6 

24,976  (49.192  characters) 


CRT  Display  Unit.  The  Display  Unit  consists  of  a CRT  screen  and  a 
keyboard  (Figure  2) . Information  typed  at  the  keyboard  is  displayed  on 
the  screen  as  each  key  is  depressed.  Information  typed  on  the  screen 
using  the  keyboard  can  then  be  transmitted  from  the  display  unit  by 
depressing  the  "SEND"  key.  Information  transmitted  to  the  display  unit 
by  the  system  is  displayed  on  the  screen;  thus,  the  display  unit  can 
transmit  data  and  receive  stored  format-display  information. 

Screen.  The  screen  is  similar  to  a small  television  screen.  Information 
typed  at  the  display  unit  keyboard  is  displayed  in  a rectangle  consisting 
of  20  lines  of  50  characters  each,  for  a total  display  capability  of  1000 
characters . 

Operator  Communication  Field  (OCF).  The  first  four  character  positions 
on  the  screen  positions  1,  2,  3.  and  4 of  line  1)  are  reserved  for 
operator  communication  codes  transmitted  by  and  to  the  operator  during 
message  receipt  and  transmission.  These  four  character  positions  are 
referred  to  as  the  Operator  Communication  Field  (OCF). 

Cursor.  A cursor  appears  on  the  screen  as  a cne-character  underline. 

The  purpose  of  the  cursor  is  to  inform  the  operator  where  on  the  screen 
the  next  character  will  appear  when  a key  is  depressed.  For  example,  in 
typing  the  word  "RETRIEVE",  the  characters  typed  and  the  cursor  appear 
as  follows: 


RETRIEV_ 

The  next  letter  to  be  typed  is  "E"  and  will  appear  directly  above  the 
cursor  when  that  key  is  depressed.  At  each  operation  of  a key  or  space 
bar,  the  position  of  the  cursor  advances  one  space.  When  the  cursor 
reaches  the  end  of  a line,  it  automatically  moves  to  the  first  position 
of  the  next  line  to  accomplish  a carriage  return.  When  the  cursor  reaches 
the  end  of  the  last  line  on  the  CRT  screen  it  automatically  returns  to 
the  first  position  of  the  first  line.  If  the  operator  makes  a typing 
error,  he  repositions  the  cursor  under  the  incorrect  character  and  either 
blanks  out  the  error  or  types  in  the  correct  character.  The  correct 
character,  or  a blank,  takes  the  place  of  the  erroneous  character. 
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Display  Unit  Keyboard.  Except  for  insignificant  differences  in  control 
keys  and  the  absence  of  lower  case  (small)  letters,  the  Display  Unit 
keyboard  (Figure  3)  is  similar  to  a standard  typewriter  keyboard. 

Control  keys  on  the  keyboard  perform  as  follows: 

(1)  Clear.  Depressing  of  the  CLEAR  key  clears  all  data  from  the 
CRT  screen.  The  cursor  is  moved  to  the  upper  left  corner  of  the  screen. 

(2)  Backspace.  Depression  of  the  BKSP  key  moves  the  cursor  one 
space  back  without  changing  displayed  data. 

(3)  Reset.  Depression  of  the  RESET  key  moves  the  cursor  to  the 
upper  left  corner  without  changing  displayed  data. 

(4)  Return.  Depression  of  the  RETURN  key  advances  the  cursor  to 
the  beginning  of  the  next  line  without  changing  displayed  data.  This 
key  performs  the  same  function  as  a manual  carriage  return  on  a type- 
writer. 

(3)  Depression  of  either  SHIFT  key  enables  entry  of  the  upper  symbol 
on  the  2-symbol  keys.  Operation  of  the  single-symbol  key  is  not  affected 
by  the  SHIFT  keys;  all  alphabetic  symbols  (letters)  are  displayed  in 
upper  case  (capital)  form.  The  SHIFT  keys  do  not  lock. 

(6)  Space  Bar.  Depression  of  the  SPACE  BAR  moves  the  cursor  one 
space  forward  without  changing  displayed  data.  This  key  has  the  same 
function  as  the  space  bar  on  a typewriter. 

(7)  Repeat.  Depression  of  the  REPT  key  causes  the  action  of  another 
depressed  key  to  be  repeated  at  a rate  of  eight  per  second  while  the 
REPEAT  key  is  depressed.  Keys  not  affected  by  the  REPEAT  key  are  CLEAR, 
SHIFT,  RESET  and  SEND. 

(8)  Erase.  The  operation  of  the  ERASE  key  erases  any  character  at 
the  position  of  the  cursor  and  advances  the  cursor  one  space. 

(9)  On/Off  Intensity.  The  ON/OFF  INTENSITY  knob  is  located  at  the 
right  side  of  the  Display  Unit.  Rotating  the  knob  clockwise  turns  the 
Display  Unit  screen  on.  Further  rotation  increases  the  intensity  of  the 
displayed  symbols.  When  the  ON/OFF  INTENSITY  control  is  off  data  can 
still  be  entered  at  the  keyboard  and  transmitted. 

(10)  Send.  Depression  of  the  SEND  key  writes  an  end -of -message 
symbol  ( ^ ) at  the  cursor  position,  and  caused  information  displayed  on 
the  screen  to  be  transmitted.  Prior  to  depressing  the  SEND  key,  the 
operator  must  ensure  that  the  cursor  is  in  position  4 of  the  Operator 
Communication  Field  (character  positions  1,  2,  3,  and  4 of  line  1 of  the 
CRT  screen)  . The  operator  should  not  hold  the  SEND  key  down  since  this 
degrades  the  operation  of  the  RSDT. 
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Figure  3.  Display  unit  keyboard 


Typewriter-Printer.  The  Typewriter-Printer  (Figure  4)  is  a modified 
office  typewriter.  TTTe  main  function  of  the  typewriter  is  to  print  out- 
put messages,  which  it  does  at  the  rate  of  13  characters  per  second. 
Information  typed  on  the  typewriter  is  transmitted  to  the  system;  however, 
it  can  transmit  only  short  codes  such  as  "ACK,"  "RPT"  or  "HLT." 

Keyboard.  The  Typewriter-Printer  prints  upper  case  alphabetic  characters. 
It  is  not  necessary  to  depress  the  shift  key  to  type  response  codes. 

Typewriter  control  settings: 

1")  Line  space  lever.  This  lever  controls  the  line  space  movement 
of  the  platen  and  has  two  settings:  double  space  and  single  space.  This 

lever  is  to  be  set  at  single  space. 

2)  Left  margin  stop.  The  left  margin  stop  is  to  be  set  at  margin 
scale  position  five. 

y)  Right  margin  stop.  The  right  margin  stop  is  to  be  set  at  the 
right  end  of  the  margin  scale. 

4 N Multiple  copy  control  lever.  To  compensate  for  additional 
copies,  this  lever  is  moved  from  the  forward  position  toward  the  rear. 

This  lever  is  to  be  set  at  the  second  position  for  2-  to  cj-  part  paper. 

Intensity  selector.  The  intensity  selector  controls  the  force 
with  which  the  typing  element  strikes  the  paper.  The  intensity  selector 
is  to  be  set  at  position  3 for  2-  to  3-  part  paper. 

■'6''  On/Off  key.  Prior  to  operation  the  operator  must  insure  that 
this  key  is  in  the  ON  position.  During  operation  the  operator  will 
insure  that  this  key  remains  in  the  ON  position.  Placing  this  key  in  the 
OFF  position  during  the  operation  can  result  in  the  loss  of  data. 


DtVTOS  Software  Characteristics 

The  software  for  DEVTOS  is  almost  entirely  custom  software  which  was 
designed,  programmed,  implemented  and  maintained  by  a highly  qualified 
team  of  Bunker  Ramo  Corporation  BRC)  software  specialists.  The  3)00 
software  is  written  in  COMPASS  and  FORTRAN  while  the  1^00  programs  are 
written  in  machine  language.  For  optimum  efficiency  and  speed  of 
execution,  BRC  prefers  to  use  COMPASS  in  most  of  the  applications. 

Software  system.  The  following  excerpt  for  BRC's  TOS  software 
brochure  describes  the  software  philosophy  utilized  in  DEVTOS. 

DEVTOS  Software  Organization.  The  DEVTOS  is  a large-scale  (240,000 
computer  instructions)  command  and  control  information  system.  The 
DEVTOS  software  system  consists  essentially  of  functional  capabil- 
ities, to  process  the  special  tasks  which  fulfill  commanders'  infor- 
mation needs  during  tactical  operations  and  operating  system 
programs,  to  control  system  and  data  manipulation  processing  and  to 
perform  the  processing  common  to  the  tactical  information 
functional)  areas. 
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Two  system  concepts  in  the  DEVTOS  give  flexibility  in  program 
operation  and  modification -- the  "modular"  operation  structure, 
and  the  "table-driven"  processing  techniques.  In  the  modular 
approach,  individual  processing  tasks  are  incorporated  as  self- 
contained,  procedurally  independent  segments  or  "modules." 

Modules  similar  or  related  in  performance  are  grouped  as 
"functions"  for  efficient  system  operation.  A module  may  be 
added,  modified,  or  deleted  with  minimal  effect  on  the  overall 
system  structure  or  its  operation. 

Table-driven  processing  imparts  desirable  flexibility  to  a 
developing  system.  Processing  paths  dependent  on  results  of 
validity  tests,  criteria  grouping,  data  storage  in  multiple  files, 
etc.,  are  selected  in  tests  and  instructions  contained  in 
"driving  tables."  Changes  in  tactical  information  requirements 
can  he  incorporated  without  restructure  of  the  basic  system  or 
additional  programming,  by  adding,  modifying,  or  deleting  driving 
tables  or  table  parameters. 

Operating  System--The  Supervisor  Software.  The  Operating  System 
consists  of  the  Executive,  General  Processes,  and  Off-line  Support 
programs . 

The  Executive  Program,  as  the  on-line  software  "director"  for  the 
DEVTOS,  dynamically  controls  all  system  processing -- inc luding 
priority  scheduling,  simultaneous  processing  of  several  "transac- 
tions" and  the  allocation  of  computer  memory  and  mass  storage; 
manages  all  equipment  resources,  and  maintains  real-time  communi- 
cation simultaneously  on  multiple  channels;  maintains  the  data 
base  from  instructions  obtained  from  General  or  Special  Processes; 
and  maintains  a log  of  system  operations,  and  collects  operating 
statistics  for  performance  analysis. 

The  General  Processes  provide  services  common  to  messages  in  all 
of  the  tactical  information  areas  i.e.,  the  functional  areas'1. 

The  direction  of  this  processing  is  prescribed  by  the  driving  tables. 
The  programs  of  the  General  Processes  perform  such  tasks  as  to 
validate  all  messages,  with  error  notification  to  originators; 
maintains  files,  retrieve  and  compare  data;  format  and  control 
dissemination  of  data  in  response  to  specific  inquiries;  automat- 
ically format  and  control  dissemination  of  data  in  response  to 
Standing  Requests  for  Information  SRI);  and  check  security  and 
restrictions  for  all  transactions  and  all  users  sending  or  receiving 
information . 

The  Off-Line  Support  programs  perform  off-line  tasks,  essential  to 
the  on-line  processing  of  the  DEVTOS,  such  as  to  translate  into 
internal  computer  language  the  external  language  used  by  analysis 
in  preparing  the  driving  tables;  reduce  data  and  generate 
statistical  reports;  and  provide  utility  services,  c.g.,  system 
tape  preparation. 
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Fiqure  4.  Typewriter-printer 
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Additional  Comments.  Generally,  all  on-line  programs  must  be  divided 
into  2K  modules  in  order  for  the  dynamic  allocation  of  core  and  the 
swapping  functions  to  operate. 

The  FORTRAN  compiler  generates  about  computer  words  of  code  for 
each  FORTRAN  statement.  In  other  words,  a FORTRAN  program  of  1000  state- 
ments would  generate  about  rj000  words  of  machine  language  code  and 
consequently  would  not  fit  into  a UO'jC  word  module. 

The  CCC  is  programmed  to  log  selectable  combinations  of  terminal 
transactions  on  a magnetic  tape.  The  subsequent  processing  of  the  log 
tape  enables  analysis  of  such  things  as  amount  of  time  the  terminals  were 
in  use,  amount  of  time  they  were  waiting  on  operator  input,  length  of  time 
it  took  for  each  operator  to  make  his  inputs,  number  of  input  errors,  etc. 
The  DEVTOS  is  quite  well  instrumented;  however,  the  people  there  advise 
that  attempts  to  log  all  transactions  slow  down  the  response  time. 

The  DEVTOS  executive  program  and  operating  system  are  unique  to 
DEVTOS.  It  was  reported  that  there  is  no  documentation  available  on  it 
other  than  design  specifications  which  are  not  necessarily  accurate  or 
up  to  date.  BRC  has  the  only  real  knowledge  and  expertise  in  this  area. 

Some  of  the  restrictions  in  the  DEVTOS  are  that  the  characters  "/" 
and  are  field  delimiters  and  not  available  for  use  (without  repro- 
grammingN . The  computer  has  an  idiosyncrasy  with  the  colon.  The  internal 
code  for  a colon  is  12  octal,  the  tape  code  for  a zero  is  12  octal,  thus 
when  colons  are  dumped  on  tape  and  subsequently  read,  they  become  zeros. 


The  organization  of  the  DEVTOS  software  system  in  Figure  5 shows  the 
program  areas  and  program  sizes  as  of  September  1/72.  For  a detailed 
description  of  each  program  area,  the  reader  is  referred  to  the  Tactical 
Operation  System  TOS^  Software  System  Description, 4 a copy  of  which  is 
in  the  AI  Project  Library. 


Synopsis  of  DEVTOS  Operational  Philosophy 

The  DEVTOS  ystem  is  designed  to  permit  on-line  storage,  update,  and 
retrieval  of  specific  tactical  and  intelligence  information.  The  philos- 
ophy has  been  to  automate  the  existing  manually  reported  information. 

The  storage  and  update  process  functions  are  as  follows: 

Specific  report  formats  are  defined  and  stored  in  the  1700 
computer.  A UI0D  operator  desiring  to  input  a certain  type 


4 Tactical  Operations  System  TOS)  Software  System  Description.  Major 
Curtis  S.  Tomlin,  USACSC-TSDG,  Systems  Analysis  Branch,  Fort  Hood, 
Texas,  January  1/72 . 
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of  data  requests  the  appropriate  format  by  typing  in  the  appro* 
priate  code.  The  1700  computer  analyzes  the  code  and  responds 
with  the  appropriate  message  or  report  format  which  is  displayed 
on  the  CRT  screen.  The  operator  then  spaces  the  cursor  down  to 
the  appropriate  space  in  the  format  and  types  in  the  information 
he  wants  in  the  data  base.  The  space  (or  field)  in  the  format 
is  marked  by  the  field  delimiters  "/"  and  The  slash  indicates 

the  beginning  of  the  field  and  the  semicolon  designates  the  end. 

The  operator  must  type  his  information  within  those  delimiters. 

When  the  operator  has  completely  filled  in  the  format  or  filled 
in  what  is  appropriate,  he  adds  the  message  precedence,  security 
classification,  and  hard  copy  indicator  and  "sends"  the  message 
to  the  3300  through  the  I7OO.  Upon  receipt  of  the  message,  the 
3300  sends  back  an  "ACK"  to  acknowledge  receipt  of  the  message. 

After  error  checking  the  message,  the  3300  sends  back  a "COR"  or 
an  "ERR"  depending  on  whether  the  message  was  correct  or  in  error. 

If  the  message  is  correct,  it  is  further  processed  and  stored  In 
the  data  base.  If  the  message  is  incorrect,  up  to  five  error 
messages  will  be  listed  on  the  last  3 lines  of  the  CRT  display 
screen. 

Hie  process  used  by  the  operator  to  retrieve  data  is  similar. 

He  types  in  a code  which  the  1700  interprets  and  responds  with  a 
message  format.  The  format  will  be  a query  format  into  which  the 
operator  will  insert  certain  parameters.  When  the  message  is  sent, 
the  3300  will  error  check  and  process  the  query.  However,  the 
response  to  the  query  will  come  back  to  the  typewriter  for  a hard 
copy  of  the  information.  The  output  will  be  in  a specific  pre- 
determined format.  The  data  input  and  query  processes  are  displayed 
in  Figure  1 on  page  13. 

Other  retrievals  possible  are  called  Special  Process  Request 
Messages  (SPR)  and  Standing  Request  for  Information  (SRI).  The 
SPR  permits  combining  functions  of  several  formats  or  requesting 
special  calculations.  The  SRI  permits  recurring  reports  to  be 
generated  on  a specific  time  table.  There  is  also  a capability 
to  relay  messages  from  one  station  to  another.  The  processing 
of  these  messages  is  similar  to  the  query  processing. 

An  interesting  feature  of  the  information  transfer  from  CRT  to  3300 
is  the  function  performed  by  the  1700  computer.  The  1700  has  all  the 
format  skeletons  stored  in  its  memory.  When  a format  is  called  for,  the 
1700  provides  it.  When  the  format  is  filled  in  and  sent  from  the  CRT,  the 
1700  strips  out  the  data,  discarding  the  format  skeleton,  adds  a key  to 
tell  the  3300  which  format  was  used,  and  sends  the  key  and  the  data  to 
the  3300.  The  3300  checks  the  key,  knows  which  format  was  used  and  pro- 
ceeds to  edit  and  error  check  the  data  accordingly.  This  saves  the 
repetitive  transmission  of  meaningless  formats  and  shortens  the  trans- 
missions considerably.  Also,  if  a typewriter  or  CRT  fails,  the  RSDT  is 
programmed  to  make  that  device  unavailable  and  notify  a designated  CRT 
or  typewriter.  I/O  devices  may  be  turned  back  on  by  notifying  the  RSDT 
via  one  of  the  operational  typewriters  or  CRTs  that  the  particular  device 
is  again  available. 
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SURVEY  OF  CAI  SYSTEMS 


This  section  describes  in  detail  the  findings  from  the  survey  and 
analysis  of  existing  computer-assisted  instruction  (CAl)  systems  for 
availability  and  feasibility  of  implementation  within  the  Developmental 
Tactical  Operations  System  (DEVTOS).  This  survey  and  analysis  provided 
the  basis  for  selections  by  the  U.  S.  Army  Research  Institute  and  the 
U.  S.  Army  Computer  System  Command  Tactical  Systems  Development  Group 
(USACSC  TSDG)  of  the  CAI  system  used  on  the  DEVTOS  system.  Parts  of  this 
section  were  written  before  the  final  debugging  of  Michigan  State  Univer- 
sity and  NSF  versions  of  PLANIT  and  are  presented  to  give  a feeling  for 
the  process  involved. 


Identifying  CAI  Systems 

A survey  which  included  the  University  of  California  at  Los  Angeles 
(UCLA)  and  System  Development  Corporation  (SDC)  libraries  covered 
journals,  indices,  reports,  computer  abstracts,  and  other  documentation. 
The  pertinent  references  are  listed  at  the  end  of  this  report.  Addi- 
tional information  was  obtained  by  telephone  contacts  and  a local  visit 
with  universities  and  private  industry.  These  contacts  are  also  listed. 


The  survey  identified  23  CAI  systems  for  which  some  data  were  avail- 
able and  which  were  not  primarily  experimental  and  limited.  These  CAI 
systems  were: 


APL 

ELIZA 

PICLS 

SCHOLAR -TEACH 

CD/TS 

FOIL 

PIL 

SIMON 

CHIMP 

LOGO 

PLANIT 

STRINGCOMP 

CLIC 

LYRIC 

PLATO 

TICCIT 

COPI 

MENTOR 

RASCAL 

WRITEACOURSE 

COURSEWRITER 

PCDP 

SCHOLAR 

Analysis  of  CAI  Systems 

Comparison  of  CAI  Systems  Against  DEVTOS  Requirements.  The  DEVTOS  re- 
quirements to  be  met  by  a CAI  system,  as  specified  in  TM-3076/OOI/OO,  were: 

1.  Is  the  system  programmed  in  FORTRAN  or  CDC  3000  COMPASS  language? 

2.  Does  the  system  operate  on,  or  can  it  be  modified  to  operate  on 
the  CDC  3300  DEVTOS  system?  This  requirement  encompasses  similarity  of 
machines  on  which  the  systems  are  operational,  upward  and  downward 
compatibility  within  a manufactured  line,  second  versus  third  generation 
hardware  and  also  the  aspect  of  system  design  for  machine  transferability. 

3.  Does  the  system  require  less  than  81,000  {2b  bit)  words  of  Core? 
This  requirement  is  dictated  by  the  maximum  core  size  of  the  DEVTOS 
computer. 
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4.  Does  the  system  require  less  than  20  million  bytes  of  Auxiliary 
storage?  This  requirement  is  dictated  by  the  DEVTOS  maximum  auxiliary 
storage. 

5.  Is  the  system  able  to  interface  to  at  least  12  CRT  displays  on- 
line? Hie  desired  medium  of  student  interface  to  the  system  is  with  CRT 
display  terminals.  Each  of  10  students  will  require  a CRT  terminal.  Two 
additional  CRT  terminals  were  used  by  project  members  for  monitor  and  control. 

6.  Does  system  interface  with  Selectric  typewriters?  A requirement 
exists  for  making  hardcopy  of  various  data. 

7.  Can  the  system  operate  under  the  control  of  a time-sharing  system? 

The  DEVTOS  operating  system  requires  that  a time-sharing  capability  exist. 

8.  Does  the  system  have  adequate  documentation  for  identifying  and 
programing  proper  interfaces  to  DEVTOS?  This  requirement  is  crucial  in 
the  interface  programming  due  to  the  limited  time  available  to  perform 
the  programming. 

9.  Does  the  system  process  a standard  character  set  identified  for 
DEVTOS?  The  DEVTOS  system  can  handle  only  a subset  of  the  characters 
generally  available  on  other  systems.  Some  of  the  characters  are  further 
restricted  in  DEVTOS. 

10.  Is  the  system  in  the  public  domain? 

Some  of  these  requirements  were  immediately  disqualifying;  the  first 
requirement,  "Is  the  system  programmed  in  FORTRAN  or  the  CDC  3300  COMPASS 
language?"  was  one  of  these.  Six  of  the  CAI  languages  qualified:  CHIMP, 

CLIC,  FOIL,  LYRIC,  PLANIT,  and  WRITEACOURSE.  Discussions  with  the 
developers  of  WRITEACOURSE  at  the  University  of  Washington  indicated 
that  it  was  not  currently  used  there  nor  known  to  be  used  elsewhere. 
Consequently,  WRITEACOURSE  was  dropped. 

The  remaining  five  CAI  systems  were  compared  against  all  the  require- 
ments. The  results  are  shown  in  Figure  6. 

Explanation  of  entries  for  DEVTOS  requirements  2 and  8 of  Figure  6: 

Item  2 

1 * extreme  difficulty  in  modifying  the  systems  is  predicted. 

2 = modification  would  be  difficult  in  that  documentation  is  a 

list  of  the  program  and  handwritten  notes  (FOIL);  or 
documentation  about  the  language  is  good  but  the  state  of 
documentation  on  the  system  is  not  known  (CHIMP) . 

4 = proven  transferability  and  operability  on  CDC  3000  series 
machines . 


- 25  - 


Item  8 


0 = no  documentation 

2 = some  documentation  but  lacks  direct  interface  points 
5 = documentation  is  adequate  but  could  use  more  detail 
4 = complete  documentation  exists 

Figure  6 indicates  that  CHIMP  and  PLANIT  ranked  above  the  other  three 
systems  in  meeting  the  DEVTOS  requirements. 


DEVTOS  REQUIREMENTS 

CHIMP 

CLIC 

FOIL 

LYRIC 

PLANIT 

1. 

FORTRAN 

Yes 

Yes 

Yes 

Yes 

Yes 

2. 

CDC  5500 

2 

1 

2 

1 

4 

3. 

CORE 

Yes 

Yes 

Yes 

Yes 

Yes 

4. 

AUX 

Yes 

Yes 

Yes 

Yes 

Yes 

5. 

CRT 

Yes 

Yes 

Yes 

Yes 

Yes 

6. 

SELECTRIC 

Yes 

Yes 

Yes 

Yes 

Yes 

7. 

OP  SYSTEM 

Yes 

Yes 

Yes 

Yes 

Yes 

8. 

DOCUMENTATION 

3 

0 

2 

4 

4 

9. 

CHARACTER 

Yes 

Yes 

Yes 

Yes 

Yes 

10. 

PUBLIC 

No 

Yes 

Yes 

No 

Yes 

Figure  6.  Comparison  of  CAI  systems  against  DEVTOS  Al  requirements 


Comparison  of  CAI  Systems  Against  Minimum  Elements  Required.  The  five 
remaining  CAI  systems  were  then  compared  against  the  minimum  essential 
elements  considered  necessary  for  a CAI  system  to  function  in  practice. 
There  were  59  of  these  elements  derived  essentially  from  a list  of  over 
90  items  compiled  by  Zinn.®-6  These  59  elements  were  determined  to  be  the 
basic  components  needed  for  a CAI  system  to  be  used  in  an  experimental 
environment.  These  59  elements  were  septrated  into  seven  groups  of 
related  elements  and  a matrix  was  prepared  for  each  group.  A "yes"  entry 


» Zinn,  K.  L.  Comparative  study  of  languages  for  programming  interactive 
use  of  computers  in  instruction!  Boston,  Mass:  Educom,  1969. 

* Zinn,  K.  L.  An  evaluative  review  of  users  of  computers  in  instruction 
Project  Clue  Tcomputer  Learning  Under  Evaluation).  Ann  Arbor,  Mich. : 
University  of  Michigan,  Center  for  Research  on  Learning  and  Teaching, 
December  1970. 
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indicates  the  element  exists  and  a "no"  entry  that  it  does  not.  Some 
elements  receive  a qualified  "yes"  or  "no"  which  is  indicated  by  an 
followed  by  an  explanation. 


MATRIX  I.  GENERAL  CHARACTERISTICS  ELEMENTS 

1)  Can  a lesson  contain  at  least  100  “frames”?* 

2)  Can  sufficient  text  be  presented  at  one  time  so  as  to  fill  a 20-line, 
50-character  DEVTOS  CRT? 

3)  Can  lessons  be  loaded  off-line  in  card  image  input? 

4)  Is  the  length  of  an  acceptable  answer  from  the  student  at  least  one 
full  line? 


Can 

the  system  give  the 

student 

multi-lined 

feedback? 

Element 

CHIMP 

CLIC 

FOIL 

LYRIC 

PLANIT 

1. 

Length 

Yes 

Yes 

Yes 

Yes 

Yes 

2. 

Test 

Yes 

Yes 

Yes 

Yes 

Yes 

3. 

Card  Input 

Yes 

Yes 

Yes 

Yes** 

Yes 

4. 

Answer 

Yes 

Yes 

Yes 

Yes 

Yes 

5. 

Feedback 

Yes 

Yes 

Yes 

Yes 

Yes 

*A  frame  is  the  basic  building  block  of  lessons.  Some  languages  do  not 
call  their  units  or  segments  frames,  but  it  is  the  most  commonly  used 
term  in  AI. 

**System  documentation  mentions  paper  tape  as  the  only  off-line  input. 
However,  this  was  in  reference  to  the  system  being  attached  to  a terminal 
using  paper  tape.  The  paper  tape  is  in  card-image  format,  hence  this 
tends  to  indicate  that  card  or  card  image  information  may  be  handled 
by  the  LYRIC  system  with  minor  adaptation. 
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MATRIX  II.  LESSON  EXECUTION  ELEMENTS 


1)  Can  the  student  be  presented  with  only  textual  material  that  does 
not  require  a response  to  question? 

2)  Can  the  system  handle  a constructed  response  type  of  answer  from  the 
student  in  which  the  student  types  a free  form  or  sentence  type 
answer? 

3)  Is  the  system  capable  of  a multiple  choice  type  question? 

(Elements  4,  5,  and  6 all  pertain  to  the  capability  of 
the  system  to  make  decisions  based  on  past  performance 
by  the  student.  Each  asks  the  question,  “Are  the 
proper  tools  for  this  task  available?’’) 

4)  Does  the  language  contain  the  following  decision  connectives:  IF, 

AND,  OR? 

5)  Does  the  language  have  at  least  the  following  or  equivalent  set  of 

logical  operators:  EOUAL,  LESS  THAN,  GREATER  THAN,  LESS  THAN  or 

EQUAL  TO,  GREATER  THAN  or  EQUAL  TO0 

6)  Can  decisions  be  based  on  every  frame  within  the  lesson? 

7)  Can  the  student  leave  in  the  middle  of  the  lesson  and  know  where  he 
is? 

8)  On  a student’s  returning  from  a lesson  which  he  did  not  complete, 
is  the  student  automatically  restarted  at  the  point  at  which  he 
stopped? 

9)  Is  there  an  automatic  review  by  topic  function  that  can  be  manipulated 
by  the  author0 


Element 

CHIMP 

CLIC 

FOIL 

LYRIC 

PLAN  IT 

1. 

Text  only 

Yes 

Yes 

Yes 

Yes 

Yes 

2. 

Constructed 

Yes 

Yes 

Yes 

Yes 

Yes 

3. 

Multiple  Choice 

Yes 

Yes 

Yes 

Yes 

Yes 

4. 

Connectives 

Yes 

Yes 

Yes 

Yes 

Yes 

5. 

Operators 

Yes 

Yes 

Yes 

Yes 

Yes 

6. 

Decisions 

Yes 

Yes 

Yes 

Yes 

Yes 

7. 

Leave 

Yes 

Yes 

Yes 

Yes 

Yes 

8. 

Restart 

No* 

>s 

y->* 

No* 

Yes 

9. 

Review 

No 

No 

No 

No 

Yes 

*The  student  must  know  and  supply  the  proper  frame  which  he  was  in  when  he 
left. 
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MATRIX  III.  LESSON  BUILDING  ELEMENTS 


1)  Does  the  language  have  a facility  to  give  a lesson  a name  and  execute 
the  lesson  by  some  command  containing  the  name  as  a component  of 

the  command? 

2)  Can  frames  be  labeled  with  a meaningful  alphanumeric  mnemonic7 

3)  Is  there  a designator  used  for  the  correct  answer? 

A)  Is  there  a designator  used  for  the  incorrect  answer? 

5)  Does  the  language  associate  a tag  with  each  answer  or  otherwise  allow 
for  several  answers  with  different  feedback  associated  with  individual 
answers? 

6)  Is  there  a facility  for  handling  unanticipated  answers? 


Element 

CHIMP 

CLIC 

FOIL 

LYRIC 

PLANIT 

1. 

Name 

Yes 

Yes 

Yes 

Yes 

Yes 

2. 

Labels 

Yes 

Yes 

Yes 

No 

Yes 

3. 

Correct 

Yes 

Yes 

Yes 

Yes 

Yes 

A. 

Incorrect 

Yes 

Yes 

Yes 

Yes 

Yes 

5. 

Answer  tags 

Yes 

Yes 

Yes 

Yes 

Yes 

6. 

Unanticipated 

Yes 

Yes 

Yes 

Yes 

Yes 

MATRIX  IV.  COUNTERS  ELEMENTS  (NOTE:  These  are  items  that  may  be  arithmet- 

ically  set  to  values  by  the  author) 

1)  Are  there  at  least  20  counters  available? 

2)  Are  the  legal  values  for  the  counters  of  a significantly  large  range? 

3)  Can  the  following  common  arithmetic  operators  be  used  with  the  counters: 
/ (divide);  **  (exponent);  + (addition);  - (subtraction);  * (multipli- 
cation) 0 

4)  Can  the  counters  be  fully  Interrogated  through  the  use  of  decision 
statements? 

5)  Can  the  author  print  the  contents  of  the  counters? 


Does  the  system  have 

counters 

for  the 

time  of  day 

? 

Element 

CHIMP 

CLIC 

FOIL 

LYRIC 

PLANIT 

1. 

Number 

Yes 

Yes 

Yes 

Yes 

Yes 

2. 

Values 

Yes 

Yes 

Yes 

Yes 

Yes 

3. 

Operators 

Yes 

Yes 

Yes 

Yes 

Yes 

4. 

Interrogation 

Yes 

Yes 

Yes 

Yes 

Yes 

5. 

Print 

Yes 

Yes 

Yes 

Yes 

Yes 

6. 

Time 

Yes 

No 

Yes 

No 

Yes 
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MATRIX  V.  ANSWER  PROCESSING  SERVICE  FUNCTIONS  ELEMENTS 


1)  Does  the  system  have  the  capability  for  allowing  misspellings  of  an 
answer? 

2)  Will  the  system  allow  for  extraneous  words  in  an  answer7 

3)  Will  punctuation  be  ignored? 

4)  Can  a partial  answer  be  acceptable  and  recorded? 


Can 

the  order  of 

a list  as  an 

answer  be 

variable 

and  still 

correct 

Element 

CHIMP 

CLIC 

FOIL 

LYRIC 

PLAN IT 

1. 

Misspelling 

No 

No 

No 

No 

Yes 

2. 

Extraneous 

Yes 

Yes 

Yes 

Yes 

Yes 

3. 

Punctuation 

Yes 

Yes 

No 

Yes 

Yes 

4. 

Partial 

Yes 

Yes 

Yes 

Yes 

Yes 

5. 

Order 

Yes 

No 

Yes 

No 

Yes 
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MATRIX  VI.  BRANCHING  ELEMENTS 


1)  Can  the  system  allow  branches  to  frame  numbers? 

2)  Can  the  system  allow  branches  to  frame  labels’ 

3)  Can  the  system  allow  branches  to  another  lesson? 


Can  the  system  branch 
branched  from? 

back  to 

the  same 

point  in 

a lesson 

It  has 

Element 

CHIMP 

CLIC 

FOIL 

LYRIC 

PLAN IT 

1 . Numbers 

Yes 

Yes 

Yes 

Yes 

Yes 

2.  Labels 

Yes 

Yes 

Yes 

No 

Yes 

3.  Lesson 

No 

Yes 

No 

No 

Yes 

4 . Back 

No 

No 

No 

No 

Yes 
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MATRIX  VII.  AUTOMATIC  STUDENT  RECORD  KEEPING  ELEMENTS 


(NOTE:  The  experimental  design  required  that  the  following 

data  be  available  for  analysis:  frame  number  or  Identifier; 

whether  the  frame  was  answered  correctly  or  incorrectly; 
the  student  latency  time  for  the  frame;  the  exact  anticipated 
answer  matched.  Only  PLANIT  and  CHIMP  record  these  items 
automatically.  In  the  three  other  systems  this  is  done  by 
the  use  of  individual  counters  which  can  be  cumbersome.) 


1)  Is  each  frame  the  student  sees  recorded? 

2)  Is  the  fact  that  the  student  answered  correct  or  incorrect  recorded? 

3)  Is  the  latency  time  for  the  frame  recorded7 

4)  Is  the  exact  anticipated  answer  matched  recorded? 


Element 

CHIMP 

CLIC 

FOIL 

LYRIC 

PLANIT 

1. 

Number 

Yes 

No* 

No* 

No* 

Yes 

2. 

Right /wrong 

Yes 

No* 

No* 

No* 

Yes 

3. 

Latency 

Yes 

No 

Yes 

No 

Yes 

4. 

Exact  answer 

Yes 

No* 

No* 

No* 

Yes 

*This  could  be  accomplished  by  the  use  of  counters. 
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Results  of  Analysis.  The  pertinent  factors  and  conclusions  derived 
from  the  analysis  are  summarized  for  each  CAI  system  as  follows: 

1.  CLIC.  CLIC  was  developed  in  the  environment  of  UT-2D  operating 
system  (CDC  65OO)  and  avails  itself  of  special  system  interfaces. 

Internal  documentation  is  practically  non-existent.  Ihere  is  also  no 
facility  for  recording  latency.  Consequently,  CLIC  did  not  meet  the 
requirements . 

2.  LYRIC . LYRIC  is  a proprietary  product  with  a single  copy  price 
of  |12,600.  LYRIC  has  no  facility  for  recording  latency.  LYRIC  is 
written  to  interface  to  an  interactive  FORTRAN  which  may  be  difficult  to 
use  in  the  DEVTOS  batch  FORTRAN  mode.  Consequently,  LYRIC  did  not  meet 
the  requirements . 

3.  FOIL.  The  FOIL  system  is  lacking  in  the  areas  of  answer  proces- 
sors and  automated  record  keeping.  The  system  has  run  only  on  IBM/360 
machines  and  it  appears  that  the  only  interface  docmuentation  is  a 
commented  listing  of  the  program.  Consequently,  FOIL  did  not  meet  the 
requirements. 

4.  CHIMP.  The  CHIMP  system  is  capable  of  handling  all  the  require- 
ments. Dr.  Munn  has  stated  that  there  should  be  no  problems  in  converting 
CHIMP  to  another  system.  Although  special  care  may  have  been  taken  in  the 
use  of  FORTRAN,  CHIMP  has  run  only  on  the  UNIVAC  1108  which  is  a third 
generation  machine  and  the  CDC  3500  in  DEVTOS  is  really  a second  gener- 
ation machine.  The  conversion  factors  of  CHIMP  are  unknown  in  both 

time  and  materials.  However,  the  input/output  of  the  two  machines  would 
be  different.  Furthermore,  the  interface  requirements  are  not  documented. 
It  is  only  known  to  be  specially  tailored  for  the  1108  and  can  be  assumed 
to  take  advantage  of  the  1108' s third  generation  capabilities.  CHIMP  is 
a proprietray  product  of  the  University  of  Maryland.  Discussions  with 
Hr.  Munn,  the  developer  of  CHIMP,  indicated  that  action  by  the  univer- 
sity board  of  trustees  would  be  needed  to  release  the  system  and  that  a 
price  or  royalty  would  be.  involved.  Whether  the  system  would  be  released 
or  what  time  and  cost  would  be  involved  was  not  known.  In  spite  of  these 
factors,  CHIMP  is  considered  an  excellent  system.  Consequently,  CHIMP 
did  meet  the  requirements  except  for  the  unknowns  discussed  above. 

3.  PLANIT.  PLANIT  meets  every  matrix  element  and  has  excellent 
interface  documentation.  At  the  time  of  the  survey  it  was  being  imple- 
mented on  a CDC  3170  at  California  State  University  at  Northridge.  The 
CDC  3170  is  very  similar  to  the  CDC  3500.  Additionally,  it  had  been 
implemented  on  numerous  other  computers.  The  PLANIT  CAI  system  tapes 
are  evidently  available  from  a number  of  possible  sources.  Consequently, 
PLANIT  does  meet  the  requirements. 


Conclusion*  from  Survey 

Two  acceptable  CAI  systems,  CHIMP  and  PLANIT,  met  the  requirements 
for  implementation  on  DEVTOS.  Certain  aspects  of  PLANIT  were  still  being 
debugged;  however,  these  were  not  considered  disqualifying.  The  status 
of  PLANIT  at  the  time  of  the  survey  is  discussed  in  the  following  section 
of  this  report. 

Based  upon  the  analysis  conducted,  PLANIT  met  the  project  requirements 
best  and  was  recommended  for  implementation  on  DEVTOS. 


Status  of  PLANIT  at  the  time  of  the  Survey 


There  were  several  sources  for  PLANIT  systems,  and  several  PLANIT 
installations.  There  was  also  a PLANIT  users  group  chaired  by  Dr.  Mort 
Rahimi,  Computer  Science  Department,  Michigan  State  University,  which 
published  a newsletter. 


Sources  for  PLANIT  systems:  1) 

2) 

3) 

4) 

Some  PLANIT  installations:  1) 


2) 

3) 

4) 

5) 


Control  Data  Corporation 
Michigan  State  University 
National  Science  Foundation 
System  Development  Corporation 

California  State  University  at 
Northridge  California  (on  CDC 

3170) 

Katholieke  University,  Nijmegen, 
Netherlands  (on  IBM  370/155) 
Michigan  State  University  (on 

CDC  65OO) 

Purdue  University  (on  CDC  65OO) 
University  of  Freiburg,  West 
Germany  (on  Siemens  4004/45) 


PLANIT  was  originally  written  by  SDC  and  operated  successfully  on  an 
IBM  Q-32  computer.  The  system  was  written  in  JOVIAL  and  interfaced  to  a 
time-sharing  operating  system.  This  system  utilized  teletypes,  Cathode 
Ray  Tubes  (CRT)  and  RAND  tablets  as  input/output  devices.  In  1968,  SDC 
received  a contract  from  the  National  Science  Foundation  to  develop  a 
prototype  of  a machine  transferable  version  of  PLANIT,  so  that  the  system 
could  interface  to  any  medium- to- large  scale  computer  operating  in  either 
batch  or  time-sharing  operating  systems.  In  December  of  1970  this  work 
was  completed.  At  that  time,  PLANIT  was  demonstrated  to  be  machine 
transferable;  it  was  transferred  from  a time-shared  XDS  940  computer 
with  a 24-bit  word  and  8-bit  byte  to  a 3^0/40  running  under  DOS,  a 
batch  operating  system,  with  a 32-bit  word  and  8-bit  byte.  Also  at 
that  time,  the  basic  system  was  demonstrated  to  be  operable.  However, 
work  on  PLANIT  was  stopped  as  there  was  no  money  available  for  quality- 
assurance  or  field  testing.  Consequently,  this  version  of  PLANIT  had 
not  been  completely  debugged  and  there  were  problems  with  it. 
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noth  SDC  and  Control  Data  Corporation  had  been  working  on  debugging 
PLANIT.  The  exact  status  of  the  CDC  PLANIT  was  unavailable,  but  sources 
reported  that  their  newest  version  was  fairly  clean.  At  that  time,  CDC 
considered  its  version  of  PLANIT  to  be  proprietary  at  a cost  of  $15,000, 
including  installation. 

The  SDC  version  of  PLANIT  had  three  major  bugs  remaining.  The  first 
involved  an  "unnamed"  lesson  in  the  PLANIT  lesson  building  mode,  which 
could  be  worked  around  by  the  lesson  designer.  The  second  limited  an 
author's  use  of  the  extensive  PLANIT  decision  language,  which  would 
restrict  him  somewhat  in  writing  lessons.  The  third  problem  was  that 
student  records  of  PLANIT  were  allocated  improperly,  so  that  several 
different  students'  records  became  jumbled  into  a single  student  record. 
For  analysis  purposes  this  was  unacceptable. 

Early  in  1971.  the  University  of  Freiburg,  Freiburg,  West  Germany, 
had  begun  an  installation  and  shakedown  of  the  PLANIT  system.  SDC 
furnished  some  program  support  and  the  PLANIT  tape  which  had  met  the 
acceptance  tests  on  SDC's  Santa  Monica  computer  but  required  considerable 
time  and  effort  before  it  became  operational  on  the  Freiburg  computer. 

Dr.  Charles  Frye,  acting  as  a private  consultant,  was  in  Freiburg 
connected  with  this  effort.  Upon  his  return  to  the  United  States  near 
the  end  of  1972,  Dr.  Frye  continued  his  PLANIT  work  at  Michigan  State 
University  and  subsequently  delivered  a copy  of  the  PLANIT  that  he  was 
using  to  the  National  Science  Foundation.  The  National  Science  Founda- 
tion has  given  a grant  to  Purdue  University  to  complete  a field  test  of 
PLANIT.  Dr.  Frye  has  been  given  an  NSF  grant  to  correct  the  remaining 
problems  and  update  the  documentation.  This  effort  was  expected  to  be 
completed  sometime  before  June  1973*  SDC  had  been  informed  by  Dr.  Frye 
of  the  following  problems  that  still  existed  but  were  to  be  corrected: 

1.  SAVE  and  GET  of  lessons  from/to  tape,  which  would  not  affect  Army 
Tactical  Data  System  for  Training  (ATDST) . 

2.  UNLOAD  student  records  to  tape  'would  not  affect  ATDST). 

3-  Pattern  matching  in  PLANIT  decision  language  (could  affect  ATDST, 
see  PLANIT  decision  language  above) . 

There  were  two  feasible  options  for  ARI  to  obtain  operational  copies 
of  a debugged  PLANIT  for  use  in  DEVTOS. 

The  first  was  through  the  National  Science  Foundation.  The  NSF 
PLANIT  was  scheduled  for  release  by  June  1973,  or  before.  The  NSF  version 
was  expected  to  be  error  free.  In  case  a few  errors  still  existed,  they 
would  be  identified  and  documented.  Ihe  contact  was: 

Mr.  Erik  D.  McWilliams 
Program  Director 
Computer  Technology  and  Systems 
Office  of  Computing  Activities 
National  Science  Foundation 
Washington,  D.C.  20550 
Phone : (202) -282-7935 
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The  second  option  was  that  Michigan  State  University  and  Control  Data 
Corporation,  under  a teaming  arrangement,  had  been  working  on  PLANIT  for 
a period  of  time,  Control  Data  Corporation  had  indicated  that  they  could 
supply  the  system,  support  it  and  guarantee  installation  on  the  CDC  3300 
for  $13,000  to  $20,000.  The  contact  was: 

Mr.  Dan  Burgess 
CDC  Computer  Systems  Division 
2200  North  Berkshire  Lane 
Minneapolis,  Minnesota 
Phone:  (612)  5k5“2851 

In  the  Interim,  SCD  supplied  a version  of  PLANIT  (and  an  accompanying 
listing)  which  was  not  completely  debugged  but  could  be  used  to  determine 
the  DEVTOS  interface  problems  and  programming  required. 


CAI  Systems 

APL  (A  Programming  Language) . A scientific-mathematical 

language  first  developed  by  IBM.  It  is  an  interactive 
language  with  several  facilities  for  CAI.  Although  the 
language  has  been  Implemented  by  several  other  computer 
vendors,  the  language  does  not  operate  on  the  CDC  3300. 
Orange  Coast  and  Golden  West  Junior  Colleges  in  Orange 
County,  California  have  used  the  language  extensively 
for  CAI. 

Contact:  Coast  Community  College  District 

Office  of  Educational  Development 
1370  Adams  Avenue 
Costa  Mesa,  Calif.  92626 
Dr.  Bernard  S.  Luskin,  Director 

and 

IBM  Corporation 

Thomas  J.  Watson  Research  Center 
P.  0.  Box  218 

Yorktown  Heights,  New  York  IO598 
Dr.  E.  N.  Adams,  Director 
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CD/TS 


CHIMP 


CLIC 


COP  I 


(Computer-Directed  Training  Subsystem) . A CAI  system,  written 
in  COBOL  for  the  Burroughs  YjOQ,  which  is  a subset  of  PLANIT. 
Developed  by  SDC  for  the  U.  S.  Air  Force. 

Contact:  Command  Systems  Division 

Electronic  Systems  Division 
Air  Force  Systems  Command 
U.  S.  Air  Force 


CAI  system  developed  hv  Institute  for  Molecular  Physics, 
University  of  Maryland.  System  is  owned  by  the  University 
and  any  release  would  have  to  be  approved  by  Board  of 
Trustees.  System  is  written  in  FORTRAN  for  the  UNIVAC  1108. 

Contact:  Robert  J.  Munn 

Professor  of  Chemistry 
Department  of  Chemistry 
University  of  Maryland 
College  Park,  Maryland 


(Conversational  Language  for  Instructional  Computing).  A 
multipurpose  CAI  language  written  in  FORTRAN  for  the  CDC  6500 
operating  under  UT-2D  operating  system  at  the  University  of 
Texas.  Although  the  system  was  once  written  to  be  trans- 
ferable, the  present  system  ‘‘has  been  developed  in  the 
environment  of  out  own  (Univ.  of  Texas)  UT-2D  operating  system 
and  avails  itself  of  special  system  interfaces ,... Internal 
documentation  is  practically  nonexistent * 

Contact:  Edwin  P.  Shaw,  Assistant  Director 

Computation  Center 
University  of  Texas  at  Austin 
Austin,  Texas  78712 


(Computer-Oriented  Programmed  Instruction).  A svstem  written 
and  marketed  by  UNIVAC  for  use  on  the  UNIVAC  1108.  The 
system  is  written  in  UNIVAC  Assemblv  language.  This  system  is 
currently  being  used  bv  the  Marine  Corps  at  29  Palms,  Calif. 

Contact:  UNIVAC 

1333  Camino  Adel  Rio  South 
San  Diego,  California 
Mr.  Ken  Corbett 


COURSEWRITER 


ELIZA 


FOIL 


LOGO  - 


The  first  author-language  for  CAI,  it  was  developed  by  IBM 
and  written  in  machine  language.  The  most  used  CAI  language 
in  the  world.  The  system  operates  all  through  the  U.S.  and 
Europe.  A COURSEWRITER  system  has  been  in  use  for  several 
years  at  Fort  Monmouth. 

Contact:  IBM  Corporation 

Thomas  J.  Watson  Research  Center 
P.0.  Box  218 

Yorktown  Heights,  N.Y.  10598 


A language  developed  by  MIT  for  the  IBM  7090  written  in  the 
LISP  language.  The  language  has  interesting  capabilities  for 
simulated  dialogue. 

Contact:  Educational  Research  Center 

Massachusetts  Institute  of  Technology 
Cambridge,  Mass. 


(File  Oriented  Interpretive  Language).  Developed  at  the 
Center  for  Research  on  Learning  and  Teaching,  University  of 
Michigan.  Written  in  IBM  FORTRAN  IV. 

Contact:  Karl  Zinn 

C R L T 

University  of  Michigan 
Ann  Arbor,  Michigan 


MENTOR  - SCHOLAR  - SIMON  - STRINGCOMP 

These  five  systems  are  all  special  experimental  CAI  languages 
developed  at  Bolt,  Beranak,  and  Newman.  All  are  written  in 
various  special-purpose  languages. 

Contact:  Bolt,  Beranak,  and  Newman,  Inc. 

Educational  Technology  Department 
50  Moulton  Street 
Cambridge,  Mass.  02138 
Wallace  Feurzeig,  Director 
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LYRIC 


PCDP 


PICLS 


PIL 


PLANIT 


(Language  for  Your  Remote  instruction  by  Computer).  A 
fully  conversational  CAI  language  developed,  trade-marked, 
sold  and  marketed  by  CAIS. 

Contact:  Computer-Assisted  Instruction  Systems 

979  Teakwood  Road 

Los  Angeles,  California  90049 

Dr.  Gloria  Silvern  Altschiller 


(Physics  Computer  Development  Project).  An  excellent 
language  specifically  suited  to  Physics  and  other  hard 
sciences  with  excellent  use  of  graphics.  Svstem  written 
in  metasymbol  for  the  XDS  Sigma-7. 

Contact:  Alfred  Bork 

PCDP 

University  of  California  at  Irvine 
Irvine,  California  92664 


(Purdue  instructional  and  Computational  Learning  .System). 
Developed  at  Purdue  University  bv  A.  Oldehoeft  for  the  CDC 
6500  in  machine  language.  Language  no  longer  used. 


(Pittsburgh  Interpretive  Language).  A CAI  svstem  written  in 
assembly  language  for  the  PDP-10.  Also  in  assembly  language 
for  the'  IBM  360  and  370. 

Contact:  Computing  Center 

University  of  Pittsburgh 
Pittsburgh,  Pennsylvania 


(Programming  Language  for  interactive  Teaching).  Originally 
written  in  JOVIAL  for  the  IBM  ANSO-32  by  SDC.  It  was 
rewritten  in  FORTRAN  and  designed  to  be  machine  transferable 
under  a NSF  grant.  PLANIT  is  generally  recognized  as  the 
most  complete  and  versatile  of  the  CAI  author  languages. 

Contact:  System  Development  Corporation 

PLANIT 

2500  Colorado  Avenue 

Santa  Monica,  California  90406 
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PLATO 


RASCAL 


SCHOLAR 


TICCIT 


(Programmed  Logic  for  Automatic  Teaching  Operation) . This 
system  is  now  in  its  fourth  generation.  Its  present  language 
is  called  TUTOR  which  is  written  in  CDC  6000  assembly  language. 
PLATO  consists  of  several  special  pieces  of  hardware  among 
them  the  PLATO  IV  Plasma  Display  Terminal 

Contact:  Dr.  Don  Bitzer,  Director 

Computer-Based  Educational  Research 
Laboratory 

University  of  Illinois 
IJrbana,  Illinois 


(Rudimentary  _Adaptive  _Sys tern  for  Computer-Aided  language). 
Produced  as  part  of  a Master’s  thesis  by  John  Christopher 
Stewart,  Lt.,  U.S.  Navy  for  a Master  of  Science  in  Computer 
Science  from  the  Naval  Postgraduate  School,  Monterey, 
California.  The  system  is  written  in  PL/1. 

Contact:  Naval  Postgraduate  School 

Monterey,  California 


TEACH  An  elementary  CAI  system  written  in  machine  language  for  the 
DEC-System  10.  Or. finally  written  by  Boeing,  Seattle, 
Washington. 


Contact:  Digital  Equipment  Corporation 

Educational  Products  Group 
Mavnard,  Mass.  01754 


(Timed- Shared , ^Interactive , COTT1Puter-Controlled  Information 
Television).  TICCIT  is  a specialized  CAI  system  using  mini- 
computers, cable  television,  and  color  television  with  keyboards 
as  input/output  devices.  The  hardware  system  is  being 
developed  by  the  Mitre  Corporation.  Courseware  is  being 
developed  by  Dr.  Victor  Bundersen  of  Brigham  Young  University. 
The  system  will  have  its  initial  testing  early  in  19T^» 

Contact:  Mitre  Corporation 

1820  Dolly  Madison  Blvd. 

McLean,  Virginia  22101 

Kenneth  J.  Stetten,  Principal  Investigator 
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WRITEACOURSE 


Originally  programmed  in  PL/1  and  more  recently  in  FORTRAN. 
The  University  of  Washington  people  indicate  it  is  not  now 
being  used  there  and  they  also  are  not  aware  of  any  use  of 
the  system  being  made  elsewhere. 

Contact:  Dr.  Earl  Hunt 

University  of  Washington 
Department  of  Psychology 
Seattle,  Washington 


SUMMARY 

Twenty- three  CAI  systems  were  identified  and  analyzed.  The  charac- 
teristics of  these  systems  were  compared  against  the  specific  require- 
ments which  must  be  met  for  a system  to  operate  in  DEVTOS.  Of  the  2J, 
six  met  the  major  requirement  that  they  be  written  in  either  the  COMPASS 
or  FORTRAN  programming  language.  One  system,  although  written  in  FORTRAN, 
was  eliminated  because  it  had  no  known  use  at  that  time.  The  five  CAI 
systems  remaining  were  analyzed  against  the  other  DEVTOS  requirements  and 
also  against  the  minimum  essential  elements  considered  necessary  for  a 
CAI  system  to  be  practically  functional.  By  the  time  these  requirements 
and  elements  had  been  considered,  two  CAI  systems — CHIMP  and  PLANIT-- 
remained.  Both  of  these  met  the  CAI  requirements  and  elements  specified. 
There  were  no  known  drawbacks  to  implementing  either  of  these  on  DEVTOS. 
However,  PLANIT--as  compared  to  CHIMP--had  a known  transferability  record, 
was  currently  on  a CDC  computer,  and  had  many  additional  capabilities  in 
regard  to  course  development  and  record  keeping.  Further,  many  univer- 
sities were  using  PLANIT  for  course  development  and  the  possibility  of 
using  these  courses  on  tactical  computers  was  attractive. 

For  the  reasons  stated  in  this  report,  PLANIT  was  clearly  identified 
as  the  CAI  system  recommended  for  implementation  in  DEVTOS. 
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GLOSSARY 


ossary  of  abbreviations  and  acronyms  is  supplied  to  aid  the  reader. 


A1 

AR1 

ARTADS 

ATDST 

BRC 

CA1 

ccc 

CDC 

CRT 

DEVTOS 

IBM 

1/0 

USSIER 

MI  OP 

MSU 

NSF 

OCF 

PLANIT 

RSDT 

SDC 

SPR 

SRI 

TOC 

TOS 

TSDG 

UCLA 

UIOD 

USACSC 


Automated  Instruction  used  interchangeably  with  (CAl^) 

Army  Research  Institute 

Army  Tactical  Data  Systems 

Army  Tactical  Data  System  for  Training 

Bunker-Ramo  Corporation 

Computer  Aided  Instruction  used  interchangeably  with  Al) 
Central  Computer  Complex 
Control  Data  Corporation 
Cathode  Ray  Tube 

Developmental  Tactical  Operations  System 
International  Business  Machines  Corporation 
Input/Output 

Modern  Army  Selected  Systems  Test  Evaluation  and  Review 

Machine  Interface  I/O  Program 

Michigan  State  University 

National  Science  Foundation 

Operator  Communication  Field 

Programming  Language  for  Interactive  Teaching 

Remote  Station  Data  Terminal 

System  Development  Corporation 

Special  Process  Request  messages 

Standing  Request  for  Information 

Tactical  Operations  Center 

Tactical  Operations  System 

Tactical  Systems  Development  Group 

University  of  California  at  Los  Angeles 

User  Input  Output  Device 

U.S.  Army  Computer  Systems  Command 
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Preceding  pege  blank 


CHARACTER  SET 


(a) 

A-Z 

Letters 

<b) 

0-9 

Numbers 

( c ) 

Space 

(d) 

• 

Period 

(e) 

» 

Comma 

(f) 

- 

Hyphen  or  minus) 

(g) 

+ 

Plus 

(h) 

= 

Equals 

(i) 

Percent 

(j) 

< 

Asterisk 

(k) 

3* 

V 

Dollar 

(1) 

( 

Left  parenthesis 

(m) 

) 

Right  parenthesis 

(n) 

> 

Semicolon 

(o) 

/ 

Slash 

(p) 

: 

Colon 

' q ) 

o 

At 

(r) 

1 

Exclamation 

(s) 

1 

Question 

(t) 

n 

Quotes 

(u) 

Number 

(v) 

< 

Less  than 

(v) 

> 

Greater  than 

(x) 

i 

Prime 

(y) 

& 

And 

- ^ - 


